le_insert_db_row
Insert a new row into a database table for FC 26, allowing you to add or update game data like player records or club details.
Instructions
Insert a database row.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| row | Yes | ||
| table | Yes |
Insert a new row into a database table for FC 26, allowing you to add or update game data like player records or club details.
Insert a database row.
| Name | Required | Description | Default |
|---|---|---|---|
| row | Yes | ||
| table | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Insert a database row', offering no details on side effects, permissions required, error conditions (e.g., duplicate key), or whether the insertion is idempotent. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 4 words, but this conciseness comes at the expense of usefulness. It lacks structure and critical information. While brevity is valued, the description should be front-loaded with essential details; here it provides only the bare minimum action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters (one nested object), no output schema, and no annotations, the description should compensate with comprehensive details. It fails to explain return values, constraints on the 'row' object, or any side effects. The description is far from complete for an insert operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters: 'table' (string) and 'row' (object), with 0% schema description coverage. The description adds no meaning beyond the schema—it does not explain what the 'row' object should contain (e.g., required fields) or valid 'table' values. This leaves the agent with no guidance on how to construct the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Insert' and the resource 'a database row', making the core action unambiguous. It distinguishes from sibling tools like le_delete_db_row and le_edit_db_field, which have different verbs. However, it could be more specific about which database or context, but it's sufficient for purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like le_edit_db_field or le_get_db_rows. It does not mention prerequisites (e.g., table must exist) or provide examples of appropriate use cases. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/INSANE0777/Fc26-live-editor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server