sanxiao-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources or actions, e.g. list_query is generic while list_projects is form-specific. However, sx_get_by_id and sx_get_bill both retrieve single bills with similar semantics, and sx_operation overlaps with specific query tools, creating minor ambiguity.
Naming Consistency3/5
All tools share the sx_ prefix, and most follow verb_noun patterns (sx_list_*, sx_get_*, sx_query_*, sx_build_*). However, sx_health and sx_capabilities are nouns rather than verbs, and there is mixing between list/get/query verbs with no strict rule, slightly reducing predictability.
Tool Count2/5
With 28 tools, the server clearly exceeds the 25-tool threshold for heavy sets. While many tools target specific query types, generic tools like sx_list_query could absorb some of them, making the surface feel redundant and bloated.
Completeness4/5
The toolset covers the full lifecycle of bills: list, get, save/update, delete, audit, submit, unsubmit, unaudit, and push. It also includes capabilities like budget queries, permissions, form config, and health checks. Only minor gaps exist, such as batch operations or specialized export tools, but core workflows are well-supported.
Average 3.1/5 across 28 of 28 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word '查询' (query) implies a read-only operation, but it does not disclose any side effects, authentication requirements, rate limits, or what data is retrieved. There is no mention of scope or any caveats. This is minimal disclosure, barely above nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length, but it lacks substance. It does not front-load any critical information beyond the basic action. While brevity is positive, the description under-specifies and offers minimal value relative to its length, so it does not score highly on structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has five parameters (two required), no output schema, and no descriptions in the schema. The description provides no context about how to construct a valid query, what the response looks like, or any constraints. It is grossly insufficient for an agent to correctly invoke this tool, especially given its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. It only mentions 'operation.materialBudget', which is not one of the schema properties. The five parameters (form_id, project_id, material_id, now_bill_id, material_type_id) are entirely unexplained, leaving an agent to guess their meaning and required formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '查询物料预算' (query material budget), which is a specific verb and resource. It distinguishes from sibling tools like sx_query_cost_budget and sx_query_working_hour_budget by specifying 'material', so an agent can identify the correct tool based on purpose. However, it essentially restates the tool name without adding deeper clarity about what 'material budget' encompasses or how it differs in behavior from the cost budget query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions. An agent has no information about whether to choose this over sx_query_cost_budget or other query tools. This is completely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the action of 'getting' a parameter, without mentioning read-only nature, authentication requirements, or side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it lacks necessary detail to be considered appropriately sized for the tool's purpose, making it under-specified. A 3 reflects adequate conciseness but insufficient completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more context about what the parameter is, what it returns, and typical use cases. It does not, so the agent lacks essential information to use the tool correctly. Score 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no explanation of the two parameters, app_code and para_code. The mention of operation.loadAppParameter does not clarify parameter meanings. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets a 'three-effect system parameter' but the term is ambiguous and not defined. It does not distinguish from sibling tools or specify the resource type beyond 'parameter'. This is vague rather than a tautology, hence a 3.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling tools (e.g., sx_get_by_id, sx_list_query). The description does not provide context or exclusions, leaving the agent to infer applicability. Score 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'query', which implies a read-only operation, but it doesn't disclose whether pagination, filtering, or any side effects exist, nor does it describe return value structure. For a tool with 8 parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is technically concise, but it is under-specified rather than efficiently informative. It front-loads nothing beyond the basic purpose and omits any essential usage details. This isn't conciseness; it's minimalism to the point of inadequacy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is completely inadequate. It doesn't explain filter criteria, pagination behavior, expected return format, or any constraints. An agent cannot reliably invoke this tool correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in the schema), and the description provides zero information about any of the 8 parameters (fields, status, bill_no, date range, pagination, ordering). The description adds no meaning beyond the parameter names, which are self-explanatory but not documented. This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('query') and resource ('loan bill', bdi_ex_loan), so an agent can understand the tool's purpose. However, it doesn't differentiate from sibling list tools like sx_list_reimbursements or sx_list_payments, which also query specific bill types, so it's not fully distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, typical scenarios, or exclusions, leaving the agent to infer that it's simply for loan bills. This is insufficient given the large number of sibling tools with similar list/query functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'queries' but does not explicitly confirm it is read-only, nor does it mention any side effects, authentication requirements, rate limits, or what happens on failure. The operation reference (operation.workingHourBudget) adds no behavioral transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which is concise, but it sacrifices essential information. It is under-specified rather than efficiently informative. There is no useful structure or front-loading of operational details; it amounts to a restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description is far from complete. It fails to explain the purpose beyond a noun phrase, lacks parameter documentation, and provides no clues about return values or error behavior. For an agent to correctly invoke this tool, it would need external knowledge or schema inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not explain any of the three parameters. The description simply repeats the tool name and operation reference, providing no meaning for form_id, project_id, or defaulted now_bill_id. An agent cannot infer what values to pass or their semantics from this text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Query working hour budget' which is a specific verb and resource, clearly indicating what the tool does. It distinguishes from the sibling tools sx_query_cost_budget and sx_query_material_budget by focusing on the working hour budget specifically. However, it does not elaborate on what a working hour budget is or what the query returns beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as sx_query_cost_budget or sx_query_material_budget. There is no mention of prerequisites, typical scenarios, or when another tool would be more appropriate. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无标注，描述需自行披露行为。'反审核'意为取消审核，属于修改操作，但描述未说明副作用、可逆性或对数据的影响，仅提及被守卫拒绝这一限制。行为透明度显著不足。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述极短且无冗余，但信息量过少，并非有效的简洁而是严重缺省。结构上可以接受，但内容不足以支持使用。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
没有输出模式，参数无说明，行为无细节，且是修改型工具，描述完全不足以让代理安全、正确地调用。缺乏基本必要信息。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
模式覆盖率为0%，描述未解释任何参数（form_id、data_id）的含义或用途。即使模式只有参数名，描述也完全没有补充信息，参数语义完全缺失。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确表明这是'反审核单据'，动词（反审核）和资源（单据）具体，且提到了官方名称'unAudit'。虽然未明确与其他工具区分，但目的基本清晰。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述仅提到'默认被只读守卫拒绝'，暗示可能需要权限但未说明何时使用此工具、有何前提或替代方案。缺少使用时机和排除条件。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only mentions 'query', implying read-only, but does not explicitly state that no side effects occur, does not describe authentication requirements, output format, or error behavior. The description is nearly silent on behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it under-specifies the tool's functionality. It is concise in length but not effective in conveying the necessary information to an agent. It lacks structure or any breakdown of behavior or parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, no annotations, and a single required parameter, the description is incomplete. It does not explain what the result will look like, how to interpret permission data, or what happens on invalid input. An agent would have to guess about the return format and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the param form_ids. It gives a vague hint that the tool deals with '若干单据' (several forms), which relates to form_ids, but does not explain what form_ids should contain (e.g., IDs vs names, format, valid types). The description adds minimal semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '查询' (query) and the resource: current user permissions on several documents (若干单据). It also references the underlying operation name, which adds specificity. However, it does not differentiate from sibling tools like sx_capabilities, which may also relate to permissions, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, not why an agent should pick it over similar tools. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is rejected by a read-only guard, implying a write/mutation operation and a potential failure mode. However, it does not describe success behavior, side effects, or required permissions. This is minimal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than concise. It omits essential information about parameters and usage, so the briefness does not serve the agent. The sentences are useful but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two required parameters and no output schema, but the description provides no parameter context or usage conditions. An agent would not know what values to supply or when to invoke this tool. The description leaves critical gaps for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention either parameter (form_id, data_id). The agent receives no explanation of what these identifiers refer to or how they should be formatted. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (审核单据 = audit documents) and resource, which is specific. However, it does not differentiate from siblings like sx_un_audit, which is the reverse operation. It's clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that by default it is rejected by a read-only guard, but does not explain conditions under which it should be used, nor does it reference any alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says '查询' (query), implying a read operation, but provides no details about pagination, ordering, filtering behavior, or limitations. Nothing beyond the bare query action is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, only two short clauses, with no wasted words. However, brevity comes at the expense of substance; it lacks structure and essential context. It is not overlong, but it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is grossly inadequate. It does not explain parameter semantics, return values, or any operational details, leaving an agent unable to make informed calls without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the 8 parameters. The mention of '分录标识' (entry identifier) does not map to any parameter. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('查询' query) and a clear resource ('工时填报' working hour filling), along with the business object code and entry identifier, which helps distinguish it from sibling list tools like sx_list_projects or sx_list_reimbursements. It is clear enough but does not go beyond the name's implied meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no context for typical use cases, and no mention of prerequisites or exclusions. The description simply restates the query purpose without directing the agent to consider other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the attach_keys parameter but does not disclose whether the operation is read-only, what permissions are needed, what the response structure is, or any side effects. The description is silent on these critical behaviors, leaving the agent to guess the nature of the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with the primary purpose front-loaded. The second clause about attach_keys is a necessary and useful clarification. No redundant words, but it could have added a bit more context without bloating. Still, it is efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is notably incomplete. It does not define what data_id and form_id refer to, does not mention the return format, and provides no error handling or edge-case guidance. An agent calling this tool would likely need to rely on examples or external knowledge, which is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 3 parameters. The description only explains attach_keys ('attachment panel identifier'), giving an example. It does not explain data_id and form_id beyond their names, which are common but still ambiguous (e.g., data_id vs document ID). With zero schema coverage, the description was expected to compensate for all parameters but only partially does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (query details by ID) and identifies the resource type (document/bill). It mentions 'official getById' which adds credibility and distinguishes it from a generic query. However, it does not explicitly differentiate from sibling tools like sx_get_bill, so it loses a point for not naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus other query tools like sx_list_query or sx_get_bill. The phrase 'official getById' implies it is the canonical way to fetch a single record, but no explicit conditions, alternatives, or exclusions are provided. The agent has to infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It mentions only keyword LIKE matching; it does not state that the operation is read-only, nor describe return format, pagination behavior, or error handling. Minimal transparency beyond the one detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) with no fluff, which is concise and front-loaded. However, its brevity sacrifices informative content; while concise, it might be considered under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, this description is far from complete. It omits pagination details, field selection, and typical return structure. It only covers keyword search, leaving many aspects an agent would need to call the tool correctly unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain parameter semantics. It explains only 'keyword' behavior, leaving 'fields', 'order_by', 'page_size', and 'page_index' entirely undocumented. The description adds some value for keyword but fails to compensate for the other four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the project archive (bdi_projectfile) and indicates keyword does LIKE matching on project name, making the resource and action explicit. However, it does not differentiate from sibling list tools, though the specific resource (projects) offers some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like sx_list_query or sx_get_by_id. The description gives no context for choosing it over other list/query tools, and there are no exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavior: '默认被只读守卫拒绝' states that by default the read-only guard rejects this operation. This is beyond the schema and useful for the agent. However, without annotations, it doesn't describe what happens on success, side effects, or how to override the guard.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loading the core action with no fluff. It consists of two short phrases. However, it omits important details, but for what it covers, the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a mutation tool with no annotations and no output schema, the description lacks essential context: what the parameters refer to, what a successful unsubmit does, and what constraints apply beyond the read-only guard. It is insufficient for an agent to call it correctly in a real scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention form_id or data_id at all. The agent must infer meaning solely from the parameter names, which is ambiguous without context. The description provides no additional semantics to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action clearly: '撤销提交' means undo submission, and '官方 unSubmit' confirms it is the official unsubmit operation. This differentiates it from siblings like sx_submit (submit) and sx_un_audit (un-audit). However, it doesn't explicitly describe the context (undoing a previously submitted form/data pair) beyond the action itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as sx_submit or sx_un_audit. No prerequisite is mentioned (e.g., the submission must exist or be in a submitted state). The note about the read-only guard is a behavioral constraint, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool checks workflow status and optionally bill presence, but it does not mention whether it is read-only, what information it returns, potential error conditions, or side effects. The lack of explicit read-only declaration is a gap for an agent assessing safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main purpose and adds a conditional detail. There is no redundant wording. However, it may be too brief to convey all necessary context, but for conciseness itself it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (2 params, no output schema, no annotations), but the description lacks essential information about return values, possible workflow states, or how to interpret results. An agent would not know what to expect from the tool's output, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meanings. It clarifies that bill_id triggers an additional check, but it does not explain the meaning or required format of form_id, which is the only required parameter. The agent cannot infer what form_id represents from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('查工作流状态' - check workflow status) and the resource (workflow). It also specifies conditional behavior based on the presence of bill_id. This makes the tool's purpose clear and distinct from most siblings, though it doesn't explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It explains what it does but not the context in which an agent should choose it over other sx_* tools, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says '查询' (query), which implies a read-only operation, but it does not explicitly state that it performs no side effects, or mention authentication, rate limits, or any other behavioral traits. Given the absence of annotations, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the tool's purpose and use case, with zero wasted words. It is appropriately concise and structured, though the brevity leaves gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, lack of output schema, and 0% parameter description coverage, the description leaves a lot unsaid. The agent does not know what form_id_ex and entry_marks do, what the return structure looks like, or whether this operation has any side effects. The description is only 'sufficient' for the most basic understanding of the tool's purpose, but not for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the lack of parameter explanations. However, it only mentions 'field identifiers' without connecting that to any of the three parameters (form_id, form_id_ex, entry_marks). form_id might be inferred from its name, but form_id_ex and entry_marks are completely unexplained. The description adds no meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (查询/query) and resource (单据字段配置/document field configuration), and adds a concrete use case: '想知道某单据有哪些字段标识时用这个' (use this when you want to know which field identifiers a document has). This distinguishes it from data-retrieval siblings like sx_get_bill or sx_get_by_id, which are about fetching actual data rather than configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives a trigger condition ('when you want to know field identifiers'), which is a clear usage signal. However, it does not state when not to use it, nor mention any alternative tools. The guidance is implied rather than explicit, so it earns a middle score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: it is rejected by default under a read-only guard. Since annotations provide no safety info, this is valuable context, but it doesn't elaborate on permissions, side effects, or failure modes. The disclosure gives partial transparency but not full coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that packs the core purpose and a critical behavioral note. It is efficiently structured with no fluff, though it might benefit from a bit more detail. Given the small size, it earns a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, no output schema, and no annotations, the description is still incomplete. It fails to explain what the parameters refer to, what happens after a successful submit, or how the guard can be bypassed. The description is too thin for an agent to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must explain parameters, but it does not. The parameter names (form_id, data_id) are somewhat self-explanatory, but the description adds no meaning about their roles or formats. This is a significant gap for an agent trying to fill required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('提交单据审批') with a specific verb and resource, and identifies it as the official 'submit' entry. It doesn't explicitly differentiate it from sibling tools like sx_un_submit or sx_audit, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that it is '默认被只读守卫拒绝' (by default rejected by the read-only guard), which hints at a precondition but does not explain when the tool should or shouldn't be used, nor does it suggest alternatives. No clear usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only explains date format and status meaning, but does not state that this is a read-only operation, nor does it mention pagination behavior, default ordering, or what happens for empty results. For a query tool, the absence of any safety or side-effect statement is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero filler. The primary purpose is front-loaded, and the supplementary format details are kept minimal. Every clause adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given eight parameters, no annotations, and no output schema, this description is far too sparse. It does not cover parameter semantics beyond two items, does not describe return values, and provides no usage examples or constraints. An agent would likely need to guess on fields, pagination, and valid statuses, making the tool under-specified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides clarification for two parameters (date format for date_from/date_to and status values like 'A' for draft), but leaves six other parameters (fields, bill_no, order_by, page_size, page_index) unexplained. This is insufficient for an agent to correctly construct calls without additional inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '查询' (query) and the resource '报销单' (reimbursement bills), including the physical table name 'bdi_ex_bx'. This distinguishes it from sibling list tools like sx_list_projects or sx_list_loans, so an agent can tell which list tool to invoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. Among many sibling list tools (e.g., sx_list_forms, sx_list_loans), there is no mention of exclusions or criteria for selecting this specific tool. It only describes what it does, not the context that would route an agent here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the destructive nature (delete) and the default read-only guard rejection, which is a crucial behavior. It does not explain consequences such as irreversibility, required authorizations, or how to properly override the guard, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with the primary purpose front-loaded ('删除单据') followed by the essential guard caveat. There is no filler or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter destructive operation with no output schema, the description provides the critical guard behavior, but it omits parameter meanings and any guidance on prerequisites or side effects. It is minimally adequate but not complete enough for an agent to use it confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions form_id or data_id, so it does not compensate for the missing parameter documentation. The schema only provides titles, which are likely insufficient for an agent to understand how the identifiers relate to the deletion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('删除' / delete) and resource ('单据' / document), and identifies itself as the '官方 delete' (official delete), which implies it is the authoritative delete among siblings. It does not explicitly name a sibling for contrast, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '默认被只读守卫拒绝' (rejected by the read-only guard by default) gives an important operational caveat about when the call will fail, which is a form of usage guidance. However, it does not explicitly state when to use this tool instead of alternatives like sx_un_submit or sx_save_or_update, leaving usage conditions only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It lists outputs but doesn't explicitly state that the operation is read-only or safe, nor does it mention any authentication requirements or side effects. The term 'health check' implies a diagnostic operation, but the absence of explicit transparency is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the purpose and key outputs with no irrelevant words. It is perfectly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health check tool, the description covers the core outputs but omits any mention of error conditions, whether it's safe to call repeatedly, or any operational context. Without annotations or an output schema, it could be more explicit about side effects and usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (coverage 100%). Per guidelines, the baseline for 0 parameters is 4. The description adds value by explaining what the health check returns, which is beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a health check and enumerates the specific data returned (gateway address, read-only switch, auth readiness, missing items). It is distinct from sibling tools that handle forms, queries, or workflows, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or when to avoid it. It doesn't mention any prerequisites, conditions, or alternatives, leaving an agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does add two genuinely useful behaviors: form_id accepts Chinese aliases, and with_attachments=True includes the default attachment panel. However, it does not state whether the operation is strictly read-only, how errors surface when data_id/form_id are invalid, or any auth requirements. The '查' verb implies non-destructiveness, but this is left implicit rather than explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with zero wasted words. The core purpose is front-loaded in the first sentence, and the second sentence adds behavioral detail without redundancy. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, 2 required, no nested objects), but with no output schema and no annotations, the description is the agent's only guide. It adequately covers the purpose and two of the three parameters, yet leaves data_id unexplained and says nothing about the return format, which matters given there is no output schema to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to form_id (Chinese alias support) and with_attachments (attachment panel behavior), both of which go beyond the bare schema. However, data_id is a required parameter that is entirely undocumented in both the schema and the description, leaving a significant semantic gap for a required field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '查任意单据详情' (query details of any bill), and highlights a distinctive feature (form_id supports Chinese aliases). It clearly communicates what the tool does. However, it does not differentiate itself from the retrieval siblings like sx_get_by_id or sx_list_query, which could overlap in purpose, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling set contains several data-retrieval tools (sx_get_by_id, sx_list_query, sx_build_query) that could serve overlapping needs, yet the description offers no exclusions, prerequisites, or routing hints. Usage context is only implied by the word '查' (query), which is insufficient given the ambiguity with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that write operations are permanently prohibited, making the read-only behavior clear. With no annotations present, this disclosure is valuable. However, it omits other behavioral details like pagination or sorting specifics, which are partially implied by parameters but not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences. The first states the purpose and resource; the second adds a critical safety note. No redundant information, and the structure is front-loaded and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, zero schema descriptions, no output schema, and no annotations, the description is woefully incomplete. It does not explain parameter formats, response structure, or usage context, making it inadequate for an agent to correctly construct and interpret a query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its 8 parameters, and the description provides no explanation of fields, status, date ranges, pagination, or ordering. The agent is left without any semantic guidance beyond parameter titles, making effective use impossible without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool queries payment bills (bdi_ex_pay), naming a specific resource and the read-only nature. It clearly differentiates from sibling list tools like sx_list_reimbursements and sx_list_loans by focusing on payment bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternative list tools. It does not mention conditions for selection, exclusions, or scenarios where another tool should be preferred, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is a mutation (save/modify) and reveals a non-obvious guard behavior: the operation is silently ignored unless environment conditions are met. This is valuable behavioral info. However, it does not mention side effects, return values, or error behavior, which would make it more complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no filler. The primary function is stated first, followed by the essential guard condition. Every word earns its place, and the structure is front-loaded with the action before the prerequisite detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no annotations, no output schema, and one complex object parameter, the description is incomplete. It omits details about bill structure, expected behavior on success/failure, and how to interpret the result. Agents lack sufficient guidance to construct a valid bill payload or handle the response appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 0% of the parameter meaning; the only parameter 'bill' is an open object with additionalProperties allowed and no description. The description does not explain what the bill structure should contain, which fields are needed, or any formatting rules. With such low schema coverage, the description was expected to compensate but fails entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'save/modify document' (保存/修改单据), which is a specific verb plus resource. It also identifies the official method (saveOrUpdate). While it doesn't name a sibling to differentiate from, the write nature is distinct from the many read/list siblings, and the core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important usage context: it is rejected by default by a read-only guard and requires specific environment settings (SX_READONLY=false and SX_ALLOW_WRITE_ACTIONS containing saveOrUpdate) to actually execute. This tells an agent when the tool will work, but it does not explicitly say when to prefer this over alternatives (e.g., sx_submit or sx_operation) or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses that the operation is read-only via the whitelist and that parameters are serialized to operationParJsonStr. However, it does not state behavior for non-whitelisted keys, return format, error handling, or authorization needs, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose front-loaded and details about the whitelist and serialization in a compact second sentence. It avoids unnecessary verbosity and is easy to scan, though the whitelist could be formatted more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a generic operation dispatcher with no output schema and no annotations, the description is incomplete. It covers the whitelist and serialization but misses return format, validation behavior, and per-operation parameter details. The existence of specific siblings might mitigate the need, but the generic tool should clarify its role and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that 'par' is a dict and will be serialized, and that 'operation_key' selects from the whitelist. But it does not describe the specific parameter structures for each operation, limiting the agent's ability to construct correct inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it executes a generic operation (三效自定义方法) and lists the whitelisted read-only operations, which helps distinguish it from specific sibling tools. However, it does not explicitly define what '三效' means or how it relates to the siblings, making differentiation partial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for invoking read-only operations from the whitelist, but it does not explicitly say when to prefer this over specific siblings like sx_get_user_permission. There is no explicit condition, exclusion, or guidance on 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that this is a query operation via 'operation.costBudget', implying read-only behavior, but does not disclose potential side effects, authentication requirements, field restrictions, or return behavior. Given it's a query, the risk is low, but transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with the primary purpose stated first and the parameter hint second. It avoids redundancy and is easy to scan. However, it is short to the point of being under-specified for a 6-parameter tool, so it doesn't hit the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is insufficient. It lacks meanings for most parameters, return format, error conditions, and any interaction with the broader workflow. An agent would struggle to understand what result to expect or how to set the parameters correctly beyond the one hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains the semantic of now_bill_id ('新建单据传 0'). The remaining five parameters (cost_id, form_id, project_id, cost_explain, cost_type_id) are left undocumented both in schema and description. The description adds a tiny amount of meaning but fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '查询费用预算' (query cost budget) with the operation name 'operation.costBudget', clearly identifying the verb, resource, and scope. It distinguishes from sibling tools like sx_query_material_budget and sx_query_working_hour_budget by the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a specific usage hint for now_bill_id when creating a new document ('新建单据传 0'), which is an actionable guideline. However, it does not explain when to use this tool versus its sibling query budget tools, nor any prerequisites or exclusions. Guidance is partially present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implicitly reveals a non-destructive, read-only nature by framing the output as listings (actions, whitelist, write actions). It does not contradict any annotations (none exist) and provides reasonable context, though it stops short of explicitly stating it has no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that front-loads the primary output ('available actions' first) and packs the three return categories efficiently with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter introspection tool with no output schema and no annotations, the description adequately conveys what is returned and its scope. It is reasonably complete, though the absence of an output schema means the return format is unspecified — a minor gap for a capabilities listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so there is nothing for the description to document. The description instead adds value by clarifying what the tool returns, which is the appropriate contribution for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: list available actions, the read-only operation whitelist, and current approved write actions. It names the specific resource (capabilities/introspection) and is distinct from siblings like sx_get_user_permission or sx_health, though it doesn't explicitly name a sibling to differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool returns but gives no guidance on when to call it versus alternatives such as sx_get_user_permission or sx_list_forms. An agent can infer it is an introspection/discovery tool, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains the query logic in detail (qParams structure, operators, field naming), which covers the mechanics of invocation. However, it does not mention that this is a read-only operation, rate limits, pagination behavior, or error scenarios. The absence of annotations raises the burden, but the detailed query syntax compensates partially, resulting in a middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet dense. It opens with a one-sentence purpose, then breaks down each parameter with concise examples in a structured format. Each line serves a purpose, and the information is front-loaded with the most critical parameters first. No redundant wording detracts from readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core input semantics comprehensively but omits return-value format, pagination behavior, and error handling. Since no output schema exists, the description should ideally hint at what the response contains to allow correct post-processing. It also does not clarify whether the tool is safe for concurrent use or whether `data_permission` affects visibility. For a general-purpose list tool, this leaves gaps in the agent's ability to plan follow-up actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate. It thoroughly explains `form_id`, `fields`, `params`, `order_by`, and `data_permission`, including syntax and examples. It misses `page_size` and `page_index`, but these have clear self-descriptive names and defaults in the schema. Overall, it adds substantial meaning beyond the bare schema, so a score of 4 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '列表查询任意三效单据' (list-query any three-criteria document), specifying a general-purpose list query tool. It establishes a distinct verb+resource pattern and differentiates from specific sibling tools like sx_list_projects by the word '任意' (any), making it unambiguous which documents it covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to prefer this tool over the specialized list tools (e.g., sx_list_projects, sx_list_reimbursements). It does not mention exclusions, preconditions, or alternatives. The '任意' implies broad applicability but lacks explicit routing context, leaving the agent to infer usage based on name similarity alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states that no request is sent, which is a key behavioral trait. It also mentions the return of a qParams array and a readable SQL-like description. However, it does not disclose details like side effects (though likely none), error handling, or any validation behaviors beyond the implication. The description provides some transparency but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. It leads with the core purpose, then details the input format, and finally describes the return value. Every sentence adds value; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is fairly complete. It explains the input format, the transformation, and the return. It lacks examples of output or more detailed operator constraints, but these are minor given the simplicity of the tool. The description provides enough for a competent agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only 'conditions' as an array with no item schema (coverage 0%). The description compensates by specifying the exact structure of each item: either a simple condition with 'key', 'op', 'value' or a grouped object with 'join' and 'children'. This adds meaningful semantics beyond the schema, though it does not enumerate allowed operators or value types, which would be even more helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (translate), the resource (simplified conditions), and the output (official qParams array). It also explicitly notes that it does not make a request, distinguishing it from sibling tools like sx_list_query that execute queries. The purpose is unambiguous and differentiates from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions '用于先验证再查询' (used for validation before querying), which provides clear context on when to use the tool. However, it does not explicitly mention when not to use it or name alternative tools, such as sx_list_query. The usage guidance is present but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full behavioral burden. It explicitly discloses that the tool performs no network calls ('不调用任何接口') and is safe in read-only environments ('只读环境下也可放心使用'). It also mentions validation and serialization, implying no side effects. This is strong disclosure given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, and the example is compact yet comprehensive. The description is efficient, using only the space needed to convey the parameter structure. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, what it returns (dataJsonStr), and when it's appropriate to use (manual verification). It covers safety and non-sending behavior. With a single parameter richly exemplified and no output schema required, the description is complete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so with a detailed JSON example of the 'bill' parameter, illustrating structure, field types (text, bd, entry), and nesting. This gives the agent concrete guidance on how to construct the input, fully compensating for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '只组装不发送' (only assemble, don't send) and '把单据 dict 校验并序列化成官方 dataJsonStr' (validate and serialize the bill dict into the official dataJsonStr). It explicitly distinguishes itself from sending tools like sx_submit and sx_push, making its unique function immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pre-submission verification by stating '供人工核对' (for manual verification) and '不调用任何接口' (doesn't call any interface). It clearly communicates that this is not for sending, but it doesn't explicitly name alternative tools for the actual submission step. Still, the context is clear enough for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有提供任何注解，因此描述承担全部行为透明性责任。描述明确了列出行为且无副作用暗示，但未明确声明这是只读操作，也未提及权限要求或数据实时性。作为纯粹列出工具，信息基本足够，但缺乏对返回行为或限制的显式说明。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
两段结构清晰，第一段直接说明主要功能和输出，第二段补充使用注意点和权威来源。没有冗余信息，关键内容前置，非常简洁高效。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于无参数、无输出模式、无注解的简单列表工具，描述已提供了核心用途、替代方案和权威来源。虽然未说明返回格式或分页行为，但在当前复杂度下已足够完整，没有重大缺失。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
工具无参数，根据规则基线为4。描述额外提及了返回的字段（formId、中文名、默认查询字段），虽未详细说明格式，但已为0参数工具提供了足够语义，故维持4分。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明了工具的功能：列出本服务已登记的三效单据标识（formId）、中文名与默认查询字段。动词'列出'清晰，资源具体，且明确区分了未登记单据仍可直接使用sx_list_query，因此与兄弟工具sx_list_query形成鲜明对照。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述直接给出了使用场景：需要获取已登记单据列表时使用本工具；未登记的单据可直接传给sx_list_query，本工具仅作为便利。这既说明了何时使用，也明确指出了替代方案，并给出了权威来源，指导性很强。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the operation returns a target data packet requiring pushPar on save, and that it is rejected by a read-only guard by default. This is important context, though it omits permission requirements and broader side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and a real-world example, second covers parameter selection and behavioral caveats. Information is front-loaded and every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: operation type, two invocation modes, and the required pushPar feedback, plus the read-only guard. Given no output schema, it does mention the returned data packet. Missing error handling or detailed response format, but not critical for a knowledgeable agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It clearly explains the roles of bill_ids, entry_ids, and src_entry_mark. src_form_id and dest_form_id are self-evident from their names, so the description adds meaningful context for the ambiguous parameters even if not all are enumerated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pushes a source document to a destination form (e.g., loan to reimbursement), using the explicit verb '下推' (push). It distinguishes from sibling tools like sx_submit or sx_audit by specifying this is an official push operation, and provides a concrete example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit parameter selection rules: use bill_ids for bill-level push, entry_ids plus src_entry_mark for entry-level push. It also flags the read-only guard default rejection, which is crucial for correct invocation. This is clear, actionable guidance that prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kingdee-sanxiao-MCP MCP server](https://glama.ai/mcp/servers/adambbhe/kingdee-sanxiao-MCP/badges/card.svg)](https://glama.ai/mcp/servers/adambbhe/kingdee-sanxiao-MCP)

Score Badge

Copy to your README.md:

[![kingdee-sanxiao-MCP MCP server](https://glama.ai/mcp/servers/adambbhe/kingdee-sanxiao-MCP/badges/score.svg)](https://glama.ai/mcp/servers/adambbhe/kingdee-sanxiao-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adambbhe/kingdee-sanxiao-MCP'

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